Skip to content

Rethink nested Paths #355

@bellebaum

Description

@bellebaum

I might need some guidance on the consumption of a presentation_submission.

Take the following example from the specification:

{
  "presentation_submission": {
    "id": "a30e3b91-fb77-4d22-95fa-871689c322e2",
    "definition_id": "32f54163-7166-48f1-93d8-ff217bdb0653",
    "descriptor_map": [
      {
        "id": "banking_input_2",
        "format": "jwt_vp",
        "path": "$.outerClaim[0]",
        "path_nested": {
          "id": "banking_input_2",
          "format": "ldp_vc",
          "path": "$.innerClaim[1]",
          "path_nested": {
            "id": "banking_input_2",
            "format": "jwt_vc",
            "path": "$.mostInnerClaim[2]"
          }
        }
      }
    ]
  }
}

According to this submission and §6.1, I should validate three nested elements with formats jwt_vp, ldp_vc and jwt_vc respectively,
to find that the innermost element is the submission for the banking_input_2 as defined in the referenced presentation definition.

I have the following questions:

  • Assume I require some freshness using a nonce as suggested in §5.2. Where would I expect such a nonce? Given the infinite nestability of paths, is there a minimum depth where it should be found (note that freshness of an inner element implies freshness of any outer element whose signature captures the inner element).
  • I guess the outermost element should be signed by the holder of the credential, while the innermost element should be signed by some issuer attesting the claims, but who should be the originator of the inbetween elements? Does it even matter given that there is no way to specify this in a presentation definition?
  • Why didn't the holder just copy the jwt_vc and include it directly in their jwt_vp?

Proposal

Unless there are good use cases against this, for which we can provide a comprehensive validation procedure, I propose to limit the scheme to at most a single nested path.

The inner element ("The credential") describes any claims being made about a subject, while the outer element ("The presentation") may serve as proof that the communicating entity is indeed the subject, usually via some proof of possession of a key involving a nonce.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions